idle_reimaginedfandomcom-20200214-history
Talk:Killer App/@comment-25739219-20141121182948
Let's start by thinking about the amazing, and then scale downward Look (above points 1 and 2) I agree with no overlapping windows. We know from lots of research that 'squishing' other windows out of the way works better than tabs. If the target is not the '300 file IDE' then we could always have everything on the screen, and expand as necessary. Usually, each learning user will be viewing an interpreter, saved code, and a tutorial in a native window or web browser. If doing anything graphical, that is usually a seperate window. Is there a way to cut these down? For example, constructs such as the IPython notebook blur saved code versus the interpreter, and can be used for some tutorials. I admit to a personal love of the programming with blocks metaphor (puzzle pieces), and would enjoy exploring its expansions. The metaphor accurately teaches people to test and run small snippets. Consider a base screen of the puzzle metaphor, with expandable snippets that go to either puzzle pieces or textual code. The idea is to suck people into a little programming with click and drag, keep showing the textual code until that looks more fun to work in, then drag them into the hard stuff, libraries. Foriegn Language Support (point 3) Internationalization is so grandiose as to make people abbreviate even the concept (i18n). While Python starts to understand this with the seperation of byte-based computer strings and unicode-based human strings, it still doesn't incorporate the idea of translation directly. I tried to get string modifiers into Python3 and was shot down hard; I suggested u'unicode', b'bytes', t'translatable', and char'customizable'. At the risk of fighting an old battle, I suggest this aggressive idea: The Idle UI comes up in the language specified in the OS. This involves tagging all translatable strings in development, gettext seems like the most likely method, and there are crowd-sourced translation engines avalable. We write custom encoders. The encoder string at the top of a Python file is usually used to handle UTF-8 vs UTF-16. Intead use # -*- coding: FR -*-, and show all Python keywords in French. Change the encoding, and we translate all the keywords to the appropriate language. Python becomes more approachable to kids around the world, at the cost of English speakers looking at other code having to have an explicit coding line. Finally, we provide a translation table tool as one of the plug-ins. That is, we teach people to use a pass through translation function for english strings and provide a full library function for i18n. Tutorial System (point 4) There are similar requirements for CodeAcademy, the Python Challenge, Tynker, and other tutorials. They all need a way to run code against an API that can watch the contents of one window and update another window. Right now, Python is hampered by the lack of a consistent language view into windowing systems. Does anyone have a clean view into how approach this? The tutorial itself would bea plug-in to a project. Is this helpful? What form of communication has the most impact for this project? Options include sharing quickly drawn video mock-ups, starting with sample users and tasks, or working on a mock-up. The only requirement for participation is that final product attempt to be really, really good.